背景

公司背景

​ 现有创业公司X，约有十名开发人员，其中技术总监一名，资深开发工程师一名，初中高级开发工程师若干，并有前端开发和测试工程师各一名。

​ 假定公司已有遵循CMMI开发规范开发的产品A，并依靠该产品维持公司开支且有少量盈余。为了扩大公司业务、实现高速发展，公司计划拓宽产品线，期望能够在维护原有产品的同时组建新的开发团队，完成新产品B的开发。

现状分析

​ 尽管CMMI模型的成熟理论和严谨规则对产品A的开发过程产生了十分正面的引导，但其过程中也产生了很多弊病：

• 写文档花费时间过多。由于公司处于创业阶段，开发人员的组成较为年轻化，一些开发人员对CMMI了解不足，在平常的开发过程中未能养成写文档的习惯，导致其在CMMI实施过程中花费了更多的时间编写了质量更低的文档，严重影响了代码效率。此外，CMMI的严谨规则也带来了文档的冗余，过多的停留于文字层面的文档影响了整体项目的开发过程。
• 难以应对变化的需求。初创团队设计的新产品正处于不断探索的阶段，因此需求不稳定，且时常变更，而这对于体量沉重的CMMI来说是难以承受的。每一次的变更，都意味着需要遵循低效的流程、推翻大量的文档，这在紧迫的创业时期内，不仅严重影响了开发团队的心情和效率，更导致人员难以完成交接，项目难以按时完成。
• 开发周期过长，成品离期望差距大。一方面，CMMI带来的大量文档工作直接导致项目周期变长；另一方面，文档中的文字有时难以像Demo（样品）一样对项目进行完好的展示，进而使得产品和需求产生偏差，而这些偏差在线性的开发过程中不断累积，最终导致交付成品和预期差距较大。

​ 丛生的弊病导致了项目A的延期交付，并间接影响了其在市场上的表现，因此在新项目B的开发过程中，公司考虑对现有开发过程进行改进，使用一种新的开发模式完成产品B的开发。

过程改进

​ 敏捷开发是一种以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发的开发方法。其在高度协作的开放环境中，使用迭代的方式进行增量开发，经常使用反馈进行思考、反省和总结，不停的进行自我调整和完善。而其中的Scrum，则是一种轻量的、易于理解的、难以精通的框架，用于高效并创造性地交付可能最高价值的产品。

​ 敏捷开发Scrum的快速跟进版本迭代的特性对创业公司的情况有很高的适应性，在创业公司团队使用Scrum常常具有以下特点：

• 替代冗余文档的是每一个能够更加精准体现项目成果的Demo（样品），替代繁复规则和流程的是个体之间的沟通交互和对变化的响应。更少的文档、更轻便的流程可以有效提升整体开发效率，而和用户需求的每一次贴合的迭代过程更能保证交付成品可以符合用户预期。
• 让客户参与开发过程。增加和客户的协作互动，能够获得最符合用户预期的精确的需求，从而降低项目开发风险，减少需求变更过程带来的开销，最终为及时交付产品提供了有力的保证。

​ 在对敏捷开发进行了一番仔细的调研后，考虑到其与创业公司良好的适应性，公司考虑改进当前软件开发模式，以敏捷开发Scrum为基础结合公司具体情况，形成了新产品B的开发过程规范模型。

设计

概述

​ 该部分阐述敏捷开发Scrum框架在公司X中的具体应用设计和相应改进，并出于对公司发展的考量，对其未来发展为中、大规模企业时软件开发模式的拓展和延申进行了讨论。其中第一阶段为初创阶段（现阶段）改进后Scrum框架在公司的应用，第二阶段为公司发展至中等规模（50-100名开发人员）时Scrum框架的拓展，第三阶段为发展至大规模（100名开发人员以上）时敏捷开发Scrum框架的延申设计。

第一阶段

概述

​ 该阶段为公司当前阶段，依赖新产品B的开发完成Scrum框架在公司软件开发过程的“落地”。这里的Scrum框架是一种经过公司特异化、实例化（在角色、工件、事件中具体表述）后和极限编程等模型相结合（在“其他改进“部分具体描述）而改进成的一种改进Scrum框架。

​ 首先需要完成敏捷开发理念和价值观的推广，为了减轻员工对新模式的抵触情绪，可以对Scrum适当地进行“本地化”改造。其次，根据万维等公司开发流程Scrum化的方案，可以采用包括持续集成平台 Jenkins、静态代码检查工具 Findbugs 和单元测试覆盖率统计工具 Eclemma等在内的辅助工具来提高 Scrum 软件开发过程中项目质量。然后开始正式实施Scrum过程。

​ Scrum框架的实施，对开发人员、产品经理和客户都提出了较高的要求。其首先要求对Scrum掌握较好的五到九名员工（几乎包括公司X的全部开发人员）组成一只Scrum团队，此团队由一名产品负责人、开发团队和一名 Scrum Master 组成，是跨职能的自组织团队，具体内容将在 “三个角色” 部分介绍。完成团队组建后，还需充分和客户沟通，争取让客户参与到项目当中。再者，需要产品负责人和客户等人沟通，由产品负责人维护一个产品待办列表，列举出所有的特性、功能、需求、增强和修复等对未来要发布的产品进行的更新，其具体内容将在 “两个工件” 部分介绍。

​ Scrum 使用固定的事件来产生规律性，以此来减少 Scrum 之外的其他会议的必要。因此在完成产品待办列表的初始化之后，需要对Scrum的核心——Sprint进行规划。Sprint一般持续一个月或更短时间，在周期内构建一个 “完成” 、可用的和潜在可发布的产品增量。Sprint 由 Sprint 计划会议、每日 Scrum 站会、开发工作、Sprint 评审会议和 Sprint 回顾 会议构成。前一个 Sprint 结束后，下一个新的 Sprint 紧接着立即开始。Sprint将在 “四个事件“ 部分被详细介绍。

一个流程

​ 图1 Scrum 框架

​ 概述部分已有对Scrum主体流程的具体阐述，这里根据图1对Scrum流程进行进一步的梳理。首先产品负责人（PO）和客户等其他人员对产品的基本需求进行讨论，设计一个由产品负责人负责维护的动态的产品待办列表（左侧Product Backlog）。此后，开始由已定义的三种角色组成的Scrum团队开始一次Sprint。Sprint由Sprint计划会议（Sprint Planning）作为开始，在该会议中，由Scrum团队来讨论该次Sprint可以完成什么工作、怎么完成每个子工作，并将选定的产品待办列表的表项加上具体交付计划组成Sprint待办列表（Sprint Backlog）。在一段Sprint期间，每天要开展每日Scrum站会（右上侧Daily Scrum），并在该站会中快速完成进度目标的巡检，依据结果调整后续计划。在Sprint快要结束时需要开展Sprint评审会议（Sprint Review），用以检视所交付的产品增量并按需调整产品待办列表。会议结果将是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。在Sprint结束后，下一个Sprint开始前，开展Sprint回顾会议（Sprint Retrospective），在会议中需要检视前一个Sprint的具体情况，也需要根据情况对团队进行相应调整，为下一个Sprint做适应。

​ 图中右侧箱子代表增量（Increment），增量是一个Sprint 完成的所有产品待办列表项的总和，以及之前所 Sprint 所产生的增量的价值总和，它必须是完成的且可用的，常常是一个产品的用于迭代的Demo（样品）。

两个工件

产品待办列表项

​ 产品待办列表是一份涵盖产品中已知所需每项内容的有序列表，是指为开发完善产品而待办的事项列表，它是产品需求变动的唯一来源。以下将说明产品待办列表的基本要求以及在公司X中的实例化结果。

基本要求

​ 它由产品负责人和客户等人进行初始化，由产品负责人负责管理其内容、可用性和排序。它具有DEEP特征：

• 适当具体化的（detailed appropriately）：对产品待办事项列表中的待办项的描述是适当具体化的。对待办项的描述，高优先级的要比低优先级的更加具体。
• 估算过的（estimated）：产品待办事项列表中的待办项都是被估算过的。这些估算值都是粗粒度的，而且通常是以故事点或者理想日为单位。知道待办项的大小可以帮助我们排列优先级并制定发布计划。
• 不断演化的（emergent）：产品待办事项列表有个有机体般的特征: 它会演化，而且它的内容会经常变化。根据客户和用户的反馈，新的待办项会被识别出来并加入到待办事项列表里面。
• 按优先级排序的（prioritized）：产品待办事项列表中的所有待办项都是按优先级排序的。最重要的、优先级最高的待办项会第一个被实现。而且它们总是在产品待办事项列表的最顶部。一旦某项完成了，就会从产品待办事项列表中移除它。

​ 产品待办列表的实质是一个按重要性的级别排序的用户故事列表，这里再对用户故事进行说明。

​ 用户故事是描述对用户有价值的功能，一个好的用户故事应该包括角色、功能和商业价值三个要素。

• 角色：到底是谁要使用这个功能，这个功能是为谁而设计的？
• 功能：这个功能是怎样的，要达到什么程度？
• 商业价值：为什么要这个功能，这个功能最后能带来什么有益的商业价值，对用户来说有什么意义？

​ 一般我们在描述一个用户故事的时候会按照以下格式：

​ 作为一个<角色>, 我想要<功能>, 以便于<商业价值>。

实例化结果

​ 在公司产品A的开发项目以及后续项目的开发过程中，要求每个产品维护一个产品待办列表，一个或多个Scrum团队的产品负责人负责管理。产品待办列表一般由产品负责人编写，再确定优先级，最后在Sprint计划会议上和开发团队进行确认。但有时开发团队也会写，比如：作为研发人员，需要写一个操作缓存的模块，这就是研发模块待办列表的初始化。

​ 重点在于用户故事的编写，项目负责人需要通过用户故事来表达清楚用户的需求，并使得开发人员领会。为了写出更好的用户故事，可以识别用户角色和虚拟人物(Personal)，从不同角度编写产品待办列表。此外，对于用户故事的规模也有不同的要求。规模较小的用户故事可以直接加入产品待办列表；规模较大的用户故事要先拆分，再加入产品待办列表进行迭代。用户故事的形式很自由，没有什么强制性的语法，但为了使产品待办列表更加易于协调，可以参考以下示例编写产品待办列表：

​ 表1 待办列表示例

				待办列表示例
ID	Name	Imp	Est	How to demo	Notes
1	存款	30	5	登录，打开存款界面，存入十元，转到我的账户余额界面，检查我的余额增加了10元	需要UML顺序图。目前不考虑加密问题。
2	查看自己的交易明细	10	8	登录，点击“交易“，存入一笔款项，返回到交易界面，看到新的存款显示再页面上	使用分页技术避免大规模的数据库查询。和查看用户列表的形式相似。

​ 用户故事编写完成后需要完成优先级的评定，可以通过不断细化功能直到某子功能的开发时间可以估算来确定优先级。例如，此次的backlog是A功能，但要做A功能的时间无法估算，拆分A功能发现要做A需要先做B功能，可要做B功能的时间也无法估算，再拆分B功能发现要先做C功能，而C功能可以估算。这时的Backlog优先级就是C→B→A。

​ 当开发团队完成了产品待办列表并不是就真正的结束了，还需要验收，或者叫用户故事的测试要点，验收标准由产品负责人自己决定或是在Sprint回顾会议和开发团队一起决定。每个团队的验收标准都不一样，有些团队以需求完成作为验收标准，有些团队以需求通过测试为验收标准，但总体的验收标准遵循DoD（Definition of Done）原则。

​ 公司X的产品待办列表要求包括：列表序号、优先级、类型、来源、用户故事、验收条件、工作量估计等基础信息，并在每个Sprint计划会议分配列表项后对Sprint列进行相应Sprint标记。此外，还需记录每个表项的状态信息：计划中、已交付、已删除，并利用不同颜色进行标记。

​ 此外，为了能够在期望时间点达成目标进度进行评估，期望产品待办列表可以完成到燃尽图（burn-downs）、燃烧图（burn-ups）或者累积流图（cumulative flows）等可视化图像的转化，从而监控整体目标实现的进度。

Sprint 待办列表

​ Sprint 待办列表是一组为当前 Sprint 选出的产品待办列表项，同时加上交付产品增量和实现 Sprint 目标的计划。以下将说明Sprint待办列表的基本要求以及在公司X中的实例化结果。

基本要求

​ Sprint 待办列表是开发团队对于下一个产品增量所需的那些功 能以及交付那些功能到 “完成” 的增量中所需工作的预测。

​ Sprint 待办列表是拥有足够细节的计划，任何进度的变化可以在每日 Scrum 站会中 清晰地看到。开发团队在 Sprint 期间修改 Sprint 待办列表，使得 Sprint 待办列表在 Sprint 期间涌现。因此相对于产品待办列表，Sprint待办列表可以监控Sprint进度，并在每日Scrum站会中让Scrum团队成员知晓Sprint评估结果。

实例化

​ Sprint待办列表表项是从产品待办列表中提取并细化而来，其列表表项中产品故事可以进行更加详细的描述。除了产品待办列表的属性，

​ Sprint待办列表还需要有计划或者任务的描述。这里类似于产品待办列表，其属性需要包括：列表序号、用户故事、任务（实现）、优先级、状态等属性，并需要列出计划完成时间和实际完成时间，用于更好地跟踪剩余工作量，管理开发团队的进度。

三个角色

产品负责人

​ 在Scrum团队中，须选定一名产品负责人PO，可以由之前的项目经理担任也可重新推举。产品负责人和客户讨论后进行项目需求梳理，从而维护产品待办列表，产品负责人是负责管理产品待办列表的唯一负责人。

​ 产品负责人的职责如下：

• 清晰地表述维护产品待办列表，使得其可以清晰显示Scrum团队下一步的工作；
• 确保产品待办列表对所有人是可见、透明和清晰的，确保开发团队对产品待办列表项有足够深的了解。

​ 公司现阶段项目——产品B的开发项目只包含一只Scrum团队，只需一位产品负责人。当未来的某产品项目包含多支Scrum团队时，可以有多位产品负责人和客户共同沟通，并维护产品待办列表，也可以容许一位产品负责人兼任多支Scrum团队的产品负责人身份的情况出现。

开发团队

​ 开发团队包含各种专业人员，是自组织的、跨职能的完整团队。在开发团队中，不认可任何子团队和任何团队头衔，团队成员应该跨越职能、能力、身份而共存。以下对其特点做具体说明：

• 自组织：开发团队应当是自组织的，即没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
• 跨职能：开发团队可以包括前端工程师、后端工程师、测试工程师等不同职能的人员，将其组织在一起可以有效克服职能化部门划分带来的不同职能团队沟通不良、竞争不利、内耗严重等缺点。

​ 为了保证敏捷性，开发团队人员不宜过多也不宜过少，少于 3 个人的开发团队，成员之间没有足够的互动，因而生产力的增长不会很大，此外 过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。而超过 9 人的团队则需要过多的协调沟通工作。对经验过程而言，大型开发团队会产生太多的复杂性而变得无用。

Scrum Master

​ Scrum Master是Scrum框架中最具特色的角色。很多公司对Scrum Master角色的理解有所偏差，直接导致了该角色在Scrum框架中的错误使用，对公司Scrum过程产生了不利的影响。这里分列基础要求和特别要求，对公司X中Scrum Master的职责和任务提出指导。

基础要求

​ Scrum Master 负责根据 Scrum 指南中的定义来促进和支持 Scrum。Scrum Master 通过帮 助每个人理解 Scrum 理论、实践、规则和价值来做到这一点。

​ Scrum Master 对 Scrum 团队而言，他/她是一位服务型领导。Scrum Master 帮助 Scrum 团队之外的人了解他/她如何与 Scrum 团队交互是有益的，通过改变他/她们与 Scrum 团 队的互动方式来最大化 Scrum 团队所创造的价值。

特别要求

​ Scrum Master是Scrum框架中最具特色的角色，此职务需要由对Scrum理解最为深刻的员工担任，也可外聘Scrum专家担任。

​ ScrumMaster应该是全方位的团队教练。作为团队教练，ScrumMaster主要关注两个层面的团队教导和培养工作：

• 过程教练（Process Coach）

过程教练就是作为Scrum师傅和守护人，帮助团队导入基于Scrum框架的敏捷开发过程及相关核心实践。通常，除了敏捷理念的宣讲和推广普及，核心过程实践的导入是指各种角色的重新定义、澄清及辅导，Scrum工件的创建和维护，敏捷需求如何拆分，如何做演进式计划，以及几个Scrum核心会议的安排和主持等事项。 ScrumMaster也需要指导团队建立工作约定，合作规则，DoD（完成的定义），DoR（Backlog准备就绪的定义）等等。

• 绩效能力教练（Performance Coach)

当团队跨过Scrum的初级导入阶段后，ScrumMaster作为团队教练就应该开始围绕打造高绩效团队及培养其持续提升能力的目标来开展工作（含针对产品负责人的辅导），更多时候是针对未知和可能性展开工作。

四个事件

Sprint 计划会议

​ 对于一个持续一个月或更短时间的Sprint而言，Sprint计划会议是Sprint中最先要举办的会议，或者说，Sprint计划会议也决定着新一次Sprint的内容。对于一个月的Sprint来说，Sprint计划会议最长为8小时，随着Sprint的缩短，相应的计划会议的时间也会缩短。Sprint计划会议通常研究以下两个问题：

• 这次Sprint能够做什么？

  ​ 首先需要由开发团队自身评估预测该次Sprint应该开发出的功能，此后根据产品待办列表、最新的产品增量以及开发团队的以往表现由开发团队自己决定选择产品待办列表项的数量。产品负责人根据这些列表项判断其要达成的目的确定此次Sprint的目标，并在最后对Sprint的目标以及过程进行详细讲解，协助整个Scrum团队理解该次Sprint工作。

• 如何完成所选的工作？

  ​ 在提取出该次Sprint要完成的产品待办列表中的列表项后，由开发团队决定如何在 Sprint 中把这些功能构建成“完成”的产品增量。这个 Sprint 中所选出的产品待 办列表项加上如何交付它们的计划称之为 Sprint 待办列表。

b) 每日 Scrum 站会

​ 每日Scrum会议是一个进行检视与适应的关键会议，它可以增进交流沟通、减少其他会议、发现开发过程中需要移除的障碍、突显并促进快速地做决策、提高开发团队的认知程度。每日Scrum会议是开发团队在每一日的开始举行的限时15分钟的事件。

​ 会议过多常常被认为是Scrum制度的一大明显缺陷，这很大程度上源于对每日Scrum站会错误或低效的开展造成的对Scrum的误解。事实上，每日Scrum站会具有很大的价值，其被认为是一种形式化，是因为没有正确地领会会议的目的，采取了不恰当的会议形式，或其它深层次的问题，导致会议不能产生预想的结果。为了从根源上避免每日Scrum站会沦为一种形式化会议，并让未来组织进入Scrum of Scrum架构后开展的更多的Scrum站会更加高效，这里对每日Scrum站会进行改进。以下分别列出原始标准的Scrum站会和改进后的Scrum站会，改进后的Scrum站会继承了原Scrum站会并对内容进行了拓展。

原每日Scrum站会

​ 在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制 定计划。通过检视上次每日 Scrum 站会以来的工作和预测即将到来的 Sprint 工作来优化团队协作和效能。每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。在会议上通常研究以下问题：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

改进后每日Scrum站会

​ 原始Scrum站会是一种鼓励讨论的更加民主式的会议，但在实际过程中，这种会议常常变成一场辩论，严重影响了会议时间，和每日Scrum会议的意图相悖。这里将Scrum站会改进为由主管主持的相对集中式的站会——所有成员群视白板，主管会按优先级顺序遍历Sprint 目标，针对细化了的每个Sprint 目标的每个任务提问三个问题：今天花了多少时间？做到了什么程度？遇到了什么问题？明天怎么解决？相关负责成员回答问题，其他成员洗耳恭听。这样的改进一方面可以节省会议时间，让站会变得不像会议、不再形式化，另一方面也可以让每位员工对其他员工的工作有更好的了解。

c) Sprint 评审会议

​ 在每个Sprint快要结束时会开展Sprint评审会议对该次Sprint完成的工作进行协同讨论。这是一个非正式会议，并不是一个进度汇报会议。对于长度为一个月的 Sprint 来说，评审会议时间最长不超过 4 小时。对于较短的 Sprint 来说，会议时间通常会缩短。在Sprint评审会议中通常包含以下内容：

• 需要邀请客户等产品利益相关者参加会议；
• 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”，并根据目前进度对可能交付日期做出评估；
• 开发团队讨论在 Sprint 期间哪些工作做的很好，遭遇到什么问题以及问题是如何解决 的，并演示“完成”的工作，通常是Demo（样品）的展示；
• 所有参会人共同讨论，根据现在市场对产品待办列表进行微调，并根据修订后的列表对下一步工作进行讨论。

d) Sprint 回顾会议

​ Sprint 回顾会议为团队提供了一个专注于检视和适应的正式机会。然而在实际的软件开发中，很多时候回顾会议往往变得无所回顾，无可总结。渐渐地流于形式，甚至被一部分开发小组所抛弃。为了避免这种情况的发生，这里对Sprint回顾会议进行改进，同每日Scrum站会类似，以下分别列出原始标准的Sprint回顾会议和改进后的Sprint回顾会议，改进后的Sprint回顾会议继承了原Sprint回顾会议并对内容进行了拓展。

原Sprint回顾会议

​ 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。对于长度为一个 月的 Sprint 来说，回顾会议时间最长不超过 3 小时。对于较短的 Sprint 来说，会议时 间通常会缩短。Sprint 回顾会议是 Scrum 团队检视自身并创建下一个 Sprint 改进计划的机会。Sprint 回顾会议的目的在于：

• 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何；
• 找出并加以排序做得好的和潜在需要改进的主要方面； 同时，
• 制定改进 Scrum 团队工作方式的计划。

改进后Sprint回顾会议

​ 对以往Sprint回顾会议出现“无所回顾“现象进行追根溯源后，我们发现Scrum轻视文档工作的特点导致了众多成员对过去一个月内Sprint的很多细节无法一一会议。因此我们可以通过将文档转化入Scrum过程来解决这一问题。具体来说，我们可以在站立白板或燃尽图边增加意见项，在每日进行Scrum站会或Sprint过程的任何时间内，可以在意见项中增加成员对于技术、沟通还是管理方面的问题提出的意见。意见项可以分成三类：提倡的建议、改进意见、揭露的弊病，意见项中还需对事件简述、日期、意见发表者进行标明。在最后进行Sprint回顾会议时相应的意见发表者可以发表更加详细的感受或意见，其余成员对此进行讨论。这样将文档转化为表项或一些可视化的事务，可以有效提升Sprint回顾会议的质量。

其他改进

适当编写文档

​ Scrum轻文档重开发的敏捷理念并不是杜绝所有的文档书写。事实上，适当地引入文档更加有利于整体开发过程，Sprint回顾会议的改进便是最好的例子。在改进Scrum框架中，可以考虑适当编写文档，使用文档来一定程度上替代沟通，这样的好处是可以形成文档依赖，便于以后有文档可查。此外，文档可以帮助新人快速熟悉小组项目，也有利于当前项目结束后的维护工作，或者是后续项目的跟进。将客户的体验形成几页纸的说明文档，可以使开发人员对客户的体验有清晰的了解。这样在每次Sprint开始之前，有了定义好的产品订单，本次Sprint便可以持续、平滑地过渡到下一次Sprint。

引入结对编程

​ Scrum提倡开发团队以跨职能、自组织形式来组织，一般要求每个开发团队每个职能员工一到两位即可。这实际上是要求每个团队成员都可独当一面、技术过硬、开发经验丰富。然而在软件行业起步晚、开发技术还相对落后的国内，鲜有具备十年研发经验的开发人员仍奋战在第一线的情形，一般开发人员都仅具有2到5年的研发经验。团队中总是无法避免出现新人（公司X便是如此），这样最终团队会出现发布的产品缺陷（Bug）多、生产率低、新手进展慢、一些模块过于依赖某一个人等许多问题。针对这样一个低效局面，尝试在Scrum基础上使用结对编程方法，每个功能模块都至少由两人负责，这样就避免了因某一人缺席而导致一些模块的研发进展停滞的情况。结对编程的过程就是一个连续代码评审的过程，这无疑会提高代码的质量，并且结对编程可促进成员相互学习、彼此提升，特别是加速了新员工的成长，从而提高了整个团队的工作效率。

坚持应用持续集成和测试驱动方法

​ 对于敏捷模式之一的Scrum，持续集成（Continuous Integration）和测试驱动（TDD）是其两大基石。在大型复杂项目实施中，软件集成无疑是一个重要的问题。要降低项目的风险、确保产品的质量，尽早且频繁、持续地集成是一种事半功倍的方法。使用测试驱动可以避免像传统方法那样对测试文档的依赖。通常用户需求的变更会使维护测试文档的成本与日俱增，这样的结果显然不够敏捷，也不符合Scrum方法的宗旨。如果使用测试代码来代替测试文档，就会使问题变得简单多了。测试驱动通过对测试代码不断地重构来推动软件功能代码的编写和完善，不断增加软件新特性，直至实现全部软件功能。这种方法不仅保证了代码的正确性，也体现了灵活适应需求变更的敏捷性。

第二阶段

概述

​ 当公司发展到中等规模（50-100名开发人员）时，简单松散的Scrum团队难以根据Scrum指南进行很好的管理，Scrum的内涵亟待扩充。这里引入适用于较大规模Scrum团队的Scrum of Scrums框架（简称SoS），对中等规模阶段公司X进行架构梳理。

​ SoS框架适用于多支Scrum团队共同并行式开发同一产品的情况，或者说它正是为此而生的。为了解决这种情况容易出现的并行团队沟通不利、透明度差等问题，SoS框架引入了分层的思想，在不同Scrum团队之上举行Scrum of Scrum会议（将在Scrum of Scrum部分详细说明），从而保持不同Scrum团队的信息同步。

​ 随着Scrum of Scrum会议的引入，原Scrum中的一些基本工件和事件的内涵被延申了，而这也对Scrum的执行带来了新的挑战。当公司继续发展到大规模或超大规模阶段时，一些巨型系统或软件的开发可能包含相当多数量的并行Scrum团队，此时简单的Scrum of Scrum产生的Scrum of Scrum会议可能会有相当多的参会人数，这一定程度上影响了沟通效率和整体项目进度。解决方案依旧十分简单，建立Scrum of Scrum of Scrums即可。这是分层思想在组织架构上的一次典型体现，不同Scrum团队作为叶子不断向上建立起了一颗Scrum树。尽管多重Scrum存在其合理性，但其层次高度亦决定了其复杂性，在实际的大规模项目Scrum框架构建中，常常采用LeSS或SAFe来消除这种复杂性或管理这种复杂性，这将是第三阶段会简单讨论的内容。

Scrum of Scrums

​ 关于谁应该代表Scrum团队参加Scrums of Scrums并没有确定的规则，这通常是由会议的主题决定的，可以首先由技术专家参加再由测试人员参加。同样，一次Scrums of Scrums会议应当包含多少人也没有确定的规则，但考虑到整体沟通效率，可以和Scrum团队人数类似——不超过9人。

​ Scrums of Scrums的上层可以继续展开Scrums of Scrums，这被称为Scrums of Scrum of Scrums。此外Scrums of Scrums不局限于任何人，可以由只有Scrum Master组成的SoS，也可以有只由产品负责人组成的SoS，只要有利于不同Scrum团队之间的沟通即可。

​ Scrums of Scrums会议开展的时间是相对的。理论上来说，在每日Scrum结束时，Scrum of Scrums应该发生——这是短期SoS，每次会议大约仅有十五分钟。但是，Scrum团队经常意识到他们实际上并不需要经常见面。 或者说，Scrum树的层级越高，不同Scrum团队之间交流次数便越少。 因此对于许多大型组织而言，已经尝试并测试了开展长期的Scrums of Scrums会议，每次持续时间超过一小时，以便能够详细讨论问题，每周两到三次的频率，减少因短期碰面造成的效率损失。

​ 在Scrum of Scrums中，讨论了与每日Scrum站会相类似的问题。但由于会议通常不会每天举行，且每个小组只有代表参会，因此三个标准问题的形式不同，并增加一个问题：

• 自上一次Scrum of Scrums以来，该团队取得了哪些成就？
• 在下次会议之前，团队将会取得什么成果？
• 是否存在阻碍团队工作的障碍？
• 一支Scrum团队会否成为另一支Scrum团队的障碍？

工件和事件的改变

​ 随着Scrum of Scrums会议的开展，原水平并行架构变得更加立体化，而这对基本工件和事件提出了新的要求。

基本事件有以下改进：

• 每日Scrums站会仍在每个团队中进行。
• Sprint评审会议应该与每个团队的所有成员一起进行。出于组织架构原因，也可以在多个Scrum级别上进行。
• Sprint回顾会议与所有团队一起进行或作为Scrum of Scrum进行。

工件则有以下改进：

• 产品待办列表：就像小框架中的Scrum一样，产品的需求被收集在产品待办列表中。 如果每个主题区域有一个待办列表，那么这些待办列表有时称为域待办列表。
• 团队待办列表：这是一种新增的待办列表。由于公司规模扩大，不同Scrum团队之间的沟通交流可能由于地域或语言问题变得更加困难，团队待办列表便因此出现。
• Sprint待办列表：每个Scrum团队根据他们的团队待办列表计划他们自己的sprint待办列表。 如果存在对其他团队需求的依赖性，则会影响优先级，但是也可能因为另一个团队依赖于它的实施，使得需求优先级变高。 在sprint结束时，每个Scrum团队都提供了部分产品增量。 正在开发的系统通过各个团队的结果逐步增长。

挑战

新的架构带来了新的挑战，Scrum of Scrums为不同角色工件事件提出了以下挑战：

• 对产品负责人而言，需要负责更多的工作，需要出席更多的会议；
• 对Scrum Master而言，需要解决可能影响所有团队的问题和团队之间依赖性的问题；
• 对于开发团队而言，由于可能更大或更加分散，需要工作的更加不自组织，沟通更加困难；
• 对于Sprint计划会议而言，计划的设定需要综合考虑多支团队的因素；
• 对于每日Scrum站会而言，由于成员可能十分分散，面对面交流可能更加难以实现；
• 对于Sprint评审会议而言，必须解释是否需要考虑整个产品或仅需要考虑团队产品；
• 对于Sprint回顾会议而言，要求更加协调的合作。

第三阶段

概述

​ 公司发展至大规模（100名开发人员以上）或超大规模时，原先的Scrum of Scrums也开始暴露出一定的缺陷，而针对这种情况的敏捷Scrum，存在两种框架：LeSS (Large Scale Scrum)和SAFe (Scaled Agile Framework)，其良好的拓展结构结合大量公司的实践经验，可以很好地支持规模化敏捷开发。这里对Less框架做一个简要的介绍。

LeSS

​ LeSS框架有应用于2-8个团队的普通规则和应用于8个团队以上产品的巨型框架规则。

​ 前者即LeSS框架规则专为最多8个团队的项目而设计。基本角色不变，但会议中的一部分会发生变化，有些会在团队级别复制。例如，冲刺计划1可能与每个团队的代表举行，而不是所有团队的所有成员。同样，与各队代表进行的跨队回顾也有助于全面改进。团队被组织为特征团队。可以以Scrum或Open Space会议的形式添加其他小组间协调会议。

​ 后者即LeSS巨型框架规则是为超过8个团队的大型项目而设计的。巨型框架增加了一个额外的角色，即区域产品负责人，他承担产品主要部分的产品所有权。在这一点上，还增加了总体冲刺回顾和回顾，以确保整体产品一致性和流程改进。除了Scrum之外，还有许多技术实践可以帮助并鼓励加强协调：持续集成。内部开放源代码（任何人都可以修改任何源代码）以及团队控制的构建系统。对于多个地点开发的项目来说，这些变得更加重要。

总结

​ Scrum框架在公司X的一步步搭建以及随着公司规模增大的一步步扩展延申的过程，实质也是Scrum自身的发展过程。从迭代式的小团队到开发一个产品包含多支并行Scrum团队，再到一个巨型系统的开发包含多个跨越若干语言区遍布全球的Scrum团队，这是公司X的全球化进程，也是Scrum的复杂化进程。

​ Scrum的复杂化进程说明了：没有完美的框架，只有不断扩充自身变得更好的框架。事务是动态发展的，人们对开发效率和管理成本也有着越来越高的追求。为了满足这种追求，从轻便到复杂再到层次化系统化， Scrum不断丰富着自己的内涵。最开始的Scrum和如今的LeSS相对比，从其官网指南来看，已然是两种不同的框架。此外，随着时代的发展，总是有新的管理方面的问题涌现，对旧的管理制度发起冲击。LeSS框架为了克服开发团队成员因为跨地域、语言区而造成难以沟通交流带来的困难所做的工作，是以往的开发规范模式从未考虑过的。因此一成不变的开发模式、制度注定会被淘汰。